Data access protection for computer systems

ABSTRACT

A protection circuit can be used with a computer system having a master device and at least one slave device that are connected by an inter-integrated circuit (I2C) bus. A first access request is received that includes an address that identifies a first slave device. In response to a permissible mode, the first access request is communicated to the first slave device using the I2C bus. A sticky protection bit can be set. In response to the sticky protection bit being set, the protection circuit can be placed in a protected mode. A second access request is received. The second access request can be determined to be a protected access to the first slave device. In response to the determining and the protected mode, the second access request to the first slave device can be denied.

BACKGROUND

The present disclosure relates to data access protection for computersystems, and more specifically, to protection of data that is accessibleusing inter integrated data buses and protocols.

Computer systems can use simple protocols to access devices during earlystages of the boot process. One such protocol is the inter-integratedcircuit (I2C) bus protocol. The I2C bus protocol can operate usingmaster device and slave devices that are connected by way of a serialcommunication bus. During the early stages of the boot process, thecomputer can write to a control register of an I2C master device. TheI2C master device can generate an I2C message on the I2C communicationbus. A slave device that corresponds to an address in the I2C messagecan respond appropriately.

SUMMARY

According to embodiments, a method is provide for using a protectioncircuit for use with a computer system having a master device and atleast one slave device that are connected by an inter-integrated circuit(I2C) bus. The protection circuit is placed in a permissible mode. Afirst access request is received that includes an address thatidentifies a first slave device. In response to the permissible mode,the first access request is communicated to the first slave device usingthe I2C bus. A sticky protection bit can be set. In response to thesticky protection bit being set, the protection circuit can be placed ina protected mode. A second access request is received that includes theaddress that identifies the first slave device. The second accessrequest can be determined to be a protected access to the first slavedevice. In response to the determining and the protected mode, thesecond access request to the first slave device can be denied.

According to embodiments, a system can be provided for use with acomputer system having a master device and at least one slave devicethat are connected by an inter-integrated circuit (I2C) bus. Aprotection circuit, in an I2C interface of the master device, can beconfigured to enter a permissible mode and to receive a first accessrequest that includes an address that identifies a first slave device.The circuit can be configured to communicate, in response to thepermissible mode, the first access request to the first slave deviceusing the I2C bus and to set a sticky protection bit. The circuit canalso be configured to place, in response to the protection bit beingset, the protection circuit in a protected mode. The circuit can receivea second access request that includes the address that identifies thefirst slave device. It can determine that the second access request isfor a protected access to the first slave device; and deny, in responseto determining that the second access request is for a protected accessand to the protected mode, the second access request to the first slavedevice.

The above summary is not intended to describe each illustratedembodiment or every implementation of the present disclosure.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The drawings included in the present application are incorporated into,and form part of, the specification. They illustrate embodiments of thepresent disclosure and, along with the description, serve to explain theprinciples of the disclosure. The drawings are only illustrative ofcertain embodiments and do not limit the disclosure.

FIG. 1 depicts a high-level block diagram of a computer system 100consistent with various embodiments of the present disclosure;

FIG. 2 depicts a system diagram for a serial interface with protectionlogic, consistent with embodiments of the present disclosure;

FIG. 3 depicts a flow diagram for startup of a computer system with aprotection circuit, consistent with embodiments of the presentdisclosure; and

FIG. 4 depicts a flow diagram for a protection circuit, consistent withembodiments of the present disclosure.

While the invention is amenable to various modifications and alternativeforms, specifics thereof have been shown by way of example in thedrawings and will be described in detail. It should be understood,however, that the intention is not to limit the invention to theparticular embodiments described. On the contrary, the intention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the invention.

DETAILED DESCRIPTION

Aspects of the present disclosure relate to protection of data stored byelectrical components of a computer system, more particular aspectsrelate to controlling access to memory devices accessible during earlyboot stages and via a configuration level protocol. While the presentdisclosure is not necessarily limited to such applications, variousaspects of the disclosure may be appreciated through a discussion ofvarious examples using this context.

Configuration level protocols, such as the inter integrated circuit(I2C) bus protocol, can be used to allow communication betweenintegrated circuit components during the early stages of startup forcomputer systems. Consistent with various embodiments, access to theintegrated circuit components through the configuration level protocols,but after the early stages, can pose security issues. Certainembodiments are directed toward data protection circuitry that isconfigured to allow access to one or more integrated circuit components,during early stages of startup (or “early boot stages”), whilerestricting access during subsequent stages of startup.

Particular embodiments are directed toward the use of a stickyprotection bit (or register) that, when set, results in the protectioncircuit being placed into a protected mode. For example, the protectioncircuit can allow access to devices during a window, and in response tothe sticky bit being set by a write, close the window and preventaccesses to devices. As discussed herein, a sticky bit cannot bereset/overwritten by a subsequent write to the bit. Moreover, accordingto various embodiments, a reset signal for the sticky bit isinaccessible to software that executes after the early stages ofstartup. For instance, the reset for the sticky bit can be linked to therebooting, or resetting, of the entire computer system. Accordingly, theprotection circuitry can be configured such that once it enters theprotected mode it will remain in the protected mode until the computersystem is reset (e.g., during a power down event, reboot, or during ahard reset). This can be useful for reducing, or eliminating, thepossibility that data stored on the integrated circuit components can beaccessed by nefarious or unauthorized programs.

Various embodiments are directed toward protection circuits that canprovide a number of different configuration options, many which can besupported both individually and collectively. For instance, aconfiguration option can indicate to the protection circuit that asubset of integrated circuit components (slave devices) are protectedfrom access and also indicate that the remaining components are toremain accessible. This could, for example, be indicated by a list thatspecifies protection status for different slave device addresses.

Turning now to the figures, FIG. 1 depicts a high-level block diagram ofa computer system 100 consistent with various embodiments of the presentdisclosure. The mechanisms and apparatus of the various embodimentsdisclosed herein apply equally to any appropriate computing system. Themajor components of the computer system 100 include one or moreprocessors 102, a memory 104, a terminal interface 112, a storageinterface 114, an I/O (Input/Output) device interface 116, and a networkinterface 118, all of which are communicatively coupled, directly orindirectly, for inter-component communication via a memory bus 106, anI/O bus 108, bus interface unit 109, and an I/O bus interface unit 110.

The computer system 100 may contain one or more general-purposeprogrammable central processing units (CPUs), herein genericallyreferred to as the processor 102. In embodiments, the computer system100 may contain multiple processors; however, in certain embodiments,the computer system 100 may alternatively be a single CPU system. Eachprocessor 102 executes instructions stored in the memory 104 and mayinclude one or more levels of on-board cache.

Consistent with embodiments, an Erasable Programmable Read-Only Memory(EPROM) 150 can store a firmware image that can be used by the processorto configure the computer system during the early stages of startup. Asdiscussed herein, the one or more processors can interface with theEPROM using a serial interface, such as an I2C interface 160. Asdiscussed herein, the I2C interface 160 can act as a master device thatcan handle requests for access to various slave devices, such as EPROM150. In various embodiments, the EPROM 150 can be a SerialElectrically-Erasable Programmable Read-Only Memory (SEEPROM). Althoughnot depicted, there can a number of additional slave devices that areaccessible by the I2C interface 160.

Aspects of the present disclosure relate to the ability to protect data(e.g., customer or user data) in situations where the protection isreliant upon the integrity of devices accessible via the I2C interface.The inclusion of protection logic within the I2C interface can allow forthe security and protection to be implemented at the device hardwarelevel (e.g., as opposed to relatively complex software security runningon the processor). The protection logic can be particularly useful forprotection against malicious computer code and for protection of thefunctional state of the system. For instance, the EPROM 150 can includeinstructions that establish and protect dedicated memory areas so thatthe data stored in the system as well as the operational state of thesystem can be safely stored. The integrity of these memories may rely onthe fact that they can be read-only memories or that they can beprotected by software layers that act as a firewall for read and/orwrite accesses to these memories.

Consistent with embodiments, memories and storage elements connected tothe processor via an I2C bus (e.g. SEEPROMs) can be protectedhardware/logic mechanisms. This can be particularly useful for providingprotection that does not rely upon software layers that might getcorrupted or that might not yet be established at the point in time thatmalicious computer code is trying to run or is already running.

In embodiments, the memory 104 may include a random-access semiconductormemory, storage device, or storage medium (either volatile ornon-volatile) for storing or encoding data and programs. In certainembodiments, the memory 104 represents the entire virtual memory of thecomputer system 100, and may also include the virtual memory of othercomputer systems coupled to the computer system 100 or connected via anetwork. The memory 104 can be conceptually viewed as a singlemonolithic entity, but in other embodiments the memory 104 is a morecomplex arrangement, such as a hierarchy of caches and other memorydevices. For example, memory may exist in multiple levels of caches, andthese caches may be further divided by function, so that one cache holdsinstructions while another holds non-instruction data, which is used bythe processor or processors. Memory may be further distributed andassociated with different CPUs or sets of CPUs, as is known in any ofvarious so-called non-uniform memory access (NUMA) computerarchitectures.

The memory 104 may store all or a portion of the various programs,modules and data structures for processing data transfers as discussedherein. These programs and data structures can be included within thememory 104 in the computer system 100, however, in other embodiments,some or all of them may be on different computer systems and may beaccessed remotely, e.g., via a network. The computer system 100 may usevirtual addressing mechanisms that allow the programs of the computersystem 100 to behave as if they only have access to a large, singlestorage entity instead of access to multiple, smaller storage entities.

The computer system 100 may include a bus interface unit 109 to handlecommunications among the processor 102, the memory 104, a display system124, and the I/O bus interface unit 110. The I/O bus interface unit 110may be coupled with the I/O bus 108 for transferring data to and fromthe various I/O units. The I/O bus interface unit 110 communicates withmultiple I/O interfaces 112, 114, 116, and 118, which are also known asI/O processors (IOPs) or I/O adapters (IOAs), through the I/O bus 108.The display system 124 may include a display controller, a displaymemory, or both. The display controller may provide video, audio, orboth types of data to a display device 126. The display memory may be adedicated memory for buffering video data. The display system 124 may becoupled with a display device 126, such as a standalone display screen,computer monitor, television, or a tablet or handheld device display. Inone embodiment, the display device 126 may include one or more speakersfor rendering audio. Alternatively, one or more speakers for renderingaudio may be coupled with an I/O interface unit. In alternateembodiments, one or more of the functions provided by the display system124 may be on board an integrated circuit that also includes theprocessor 102. In addition, one or more of the functions provided by thebus interface unit 109 may be on board an integrated circuit that alsoincludes the processor 102.

The I/O interface units support communication with a variety of storageand I/O devices. For example, the terminal interface 112 supports theattachment of one or more user I/O devices 120, which may include useroutput devices (such as a video display device, speaker, and/ortelevision set) and user input devices (such as a keyboard, mouse,keypad, touchpad, trackball, buttons, light pen, or other pointingdevice). A user may manipulate the user input devices using a userinterface, in order to provide input data and commands to the user I/Odevice 120 and the computer system 100, and may receive output data viathe user output devices. For example, a user interface may be presentedvia the user I/O device 120, such as displayed on a display device,played via a speaker, or printed via a printer.

The storage interface 114 supports the attachment of one or more diskdrives or direct access storage devices 122 (which are typicallyrotating magnetic disk drive storage devices, although they couldalternatively be other storage devices, including arrays of disk drivesconfigured to appear as a single large storage device to a hostcomputer, or solid-state drives, such as flash memory). In someembodiments, the storage device 122 may be implemented via any type ofsecondary storage device. The contents of the memory 104, or any portionthereof, may be stored to and retrieved from the storage device 122 asneeded. The I/O device interface 116 provides an interface to any ofvarious other I/O devices or devices of other types, such as printers orfax machines. The network interface 118 provides one or morecommunication paths from the computer system 100 to other digitaldevices and computer systems; these communication paths may include,e.g., one or more networks 130.

Although the computer system 100 shown in FIG. 1 illustrates aparticular bus structure providing a direct communication path among theprocessors 102, the memory 104, the bus interface unit 109, the displaysystem 124, and the I/O bus interface unit 110, in various embodimentsthe computer system 100 may include different buses or communicationpaths, which may be arranged in any of various forms, such aspoint-to-point links in hierarchical, star or web configurations,multiple hierarchical buses, parallel and redundant paths, or any otherappropriate type of configuration. Furthermore, while the I/O businterface unit 110 and the I/O bus 108 are shown as single respectiveunits, the computer system 100 may, in fact, contain multiple I/O businterface units 110 and/or multiple I/O buses 108. While multiple I/Ointerface units are shown, which separate the I/O bus 108 from variouscommunications paths running to the various I/O devices, in otherembodiments, some or all of the I/O devices are connected directly toone or more system I/O buses.

In various embodiments, the computer system 100 is a multi-usermainframe computer system, a single-user system, or a server computer orsimilar device that has little or no direct user interface, but receivesrequests from other computer systems (clients). In other embodiments,the computer system 100 may be implemented as a desktop computer,portable computer, laptop or notebook computer, tablet computer, pocketcomputer, telephone, smart phone, or any other suitable type ofelectronic device.

FIG. 1 depicts a representative of certain major components of thecomputer system 100. Individual components, however, may have greatercomplexity than represented in FIG. 1, components other than or inaddition to those shown in FIG. 1 may be present, and the number, type,and configuration of such components may vary. Several particularexamples of additional complexity or additional variations are disclosedherein; these are by way of example only and are not necessarily theonly such variations.

FIG. 2 depicts a system diagram for a serial interface with protectionlogic, consistent with embodiments of the present disclosure. Consistentwith embodiments, processor chip 202 can be configured to interface withone or more slave devices 214, 216, 218 over a configuration levelinterface, e.g., a serial communication interface, such as an I2C bus.For example, the processor can include an I2C master interface 212,which translates access requests received over an internal communicationbus to an I2C bus protocol message. The I2C master interface can accesseach of the slave devices using a respective and corresponding deviceidentifier (ID) or address. In certain embodiments, the slave addresscan be a set number of bits (e.g., eight) with the last bit specifyingwhether the access request is a write or read request. Thus, FIG. 2shows the slave devices as each having two device IDs, one for reads andone for writes. It is understood, however, that this same use of bitscould be viewed as a single, seven-bit address, with an additional bitthat is a read/write indicator.

Consistent with embodiments, the entire eight bit address (therebydenoting read or write access) can be stored within the protectedlist(s) used by the protection device. This can allow fordevice-by-device granularity on, not only whether protection is enabledfor a device, but whether the protection is read, write, or both. Forinstance, a slave device have an address corresponding to the 7 bits:1101001. For writes, the slave device will respond to the 8 bits:11010010, and for reads, the slave device will respond to the 8 bits11010011. The protection list(s) can include one or both of these 8 bitsdepending on whether or not the protection corresponding to the list isfor reads, writes, or both.

According to various embodiments, the I2C master interface 212 caninclude a protection circuit 206. Consistent with embodiments, theprotection (logic) circuit can be implemented using logic circuitry,discrete components, programmable logic, firmware, and combinationsthereof. When an access request is received over the internalcommunication bus, the protection circuit 206 can be configured to allowor deny the request depending upon the particular configuration of thesystem. For example, certain embodiments allow for the use of a list ofprotected devices 204. When an access request is received, theprotection circuit can check the list as part of the determinationwhether or not to allow the request to reach the targeted slave device.Consistent with embodiments, the list 204 could be formatted indifferent manners. For example, the list could specify devices that arenot protected, and protect any device that is not in the list. Inanother example, the list could include all device IDs and includeadditional data that specifies whether the corresponding device isprotected. Other information in the list could include whether thedevice is read protected, write protected, or both. Moreover, an addresscan considered to be within the list whether the address is individuallyspecified in the list, or included as part of a range of addresses.

In some embodiments, a protection list can specify different protectiondepending upon the source of the access request. For instance, thecomputer system can include contain multiple devices or circuits thatcan each generate access requests specifying slave devices on the I2Cbus. Each of the devices can be identified by a corresponding sourceaddress. The protection circuit can check the list of protected devicesrelative to the source address. For example, a first source addresscould be for a computer processor circuit and as second source addresscould be for a secure device that is more secure than the computerprocessor circuit (e.g., the second device may have limited, or nor,re-programmability). Accordingly, and address for the processor circuitcould be included in the list while an address for the secure device isnot. When the protection circuit is in the protected mode, this list canbe consulted by the protection circuit, which can thereby determine thataccesses by the processor circuit would be limited, while accesses bythe secure device would be allowed.

Various embodiments allow for more complex lists and combinations oflists to be used. For example, a list could specify one or more sourcedevice addresses and also one or more slave device addresses. Theprotection circuit could be configured to limit access to the slavedevices in the list for those source device addresses that are also inthe list. Other source devices could then be allowed to access the slavedevices in the list (assuming the source devices was not in anotherprotection list).

Consistent with embodiments, the protection circuit 206 can beconfigured to operate in different modes depending upon the level ofprotection that is desired. For example, the protection circuit can beconfigured to operate in a permissible, or unprotected, mode during theearly stages of the boot process. In a particular example, one of theslave devices can store (boot loader) instructions that are used toconfigure the computer system during these early stages of the bootprocess. In some instances, this slave device can be configured toinclude setup protections on certain data, such as by creating protectedmemory areas that cannot be overridden by subsequently loaded software(which may have been compromised or corrupted).

According to embodiments, a slave device that is used during the earlystages of the boot process can also have the capability of being updatedwith new instructions. The processor starts booting out of the trustedbootloader code stored on the EPROM. The processor can use thebootloader code as the root of trust in the system. Because no othersoftware is being run by the processor, the sticky bit can remain unsetin order to allow updates to the bootloader. In certain embodiments,there is no other code that can run at this point, which can be relevantto the security of the system. At the end of the execution of thebootloader code, the bootloader code can instruct the processor to copya firmware image out of an attached flash memory into the processorscache memory. Before the bootloader code triggers the processor to beginexecution of the firmware image, the bootloader code can evaluate thetrust in the firmware image that has been moved to cache. For example,process can verify the image against a hash value stored in the EPROMalong with the bootloader code. If the firmware image matches theexpected hash value, then the processor can assume that the bootloadercode is still in control of the processor. The processor can stopexecuting the bootloader code and begin execution of the firmware imagestored in the cache. The firmware image can be configured to instructthe processor to check the flash memory for any potential signed andtrusted EPROM update images. If they are found, they can be moved themto the EPROM. Next, the processor can set the sticky bit, which canprevent further modifications of the EPROM. The processor can thencontinue to boot the system, which may eventually include the executionof untrusted software.

Consistent with various embodiments, the protection circuit can use asticky register or bit 208 to control when access to slave device(s) isrestricted. For instance, the trusted firmware can generate an accessprotection enable signal that sets the sticky bit 208. While FIG. 2depicts the access protection enable signal as a dedicated signal,various embodiments allow for the use of the internal communication busto set the sticky bit. For example, the protection circuit can map aregister bit, of a configuration register space, to the sticky bit. Thetrusted firmware can then write to the configuration register bit toenable the protection circuit. Once enabled, the sticky bit can beconfigured such that it is only cleared when the computer system isreset in a manner that the trusted firmware is in control of the system.This condition may occur during power cycling, a reset action, or otherevent that places the computer system in a similar state.

According to various embodiments, the protection circuity can beconfigured to use multiple sticky bits. For example, each sticky bit cancorrespond to a different set of protected devices. This can allow fordifferent access windows to be used for different sets of protecteddevices. Thus, a first sticky bit can be used to protect bootloader codestored in an EPROM device from being tampered with. As discussed herein,this first sticky bit can be set relatively early in the boot process. Asecond sticky bit, however, may remain unset until later in the bootprocess. For example, the second sticky bit could be associated with I2Cdevices that include memory space that is used during the execution of afirmware image out that was loaded from an attached flash memory for useafter the bootloader code was terminated. Once the firmware image passescontrol to other software, such as an operation system, the secondsticky bit can be set to protect the memory space used by the firmwareimage. Additional sticky bits can also be used, depending upon theapplication. Consistent with embodiments, each sticky bit can be linkedto a different protected list.

FIG. 3 depicts a flow diagram for startup of a computer system with aprotection circuit, consistent with embodiments of the presentdisclosure. The system can first startup and the protection circuit canenter a permissible mode that allows access to slave devices over anexternal interface, as shown by block 302. This may occur in response toa power on event, reset event, or similar event. The processor(s) of thecomputer system can begin a self-boot routine that can includestabilizing the power for the processor, and configuring or enabling anexternal interface (e.g., I2C interface), per block 304. The system canthen use the external (I2C) interface to access a firmware image thatcontains boot code and that is stored in a slave device, per block 306.The boot code can then be executed in order to initialize the processorand other chipset components within the computer system, as shown byblock 308.

The boot code can also include instructions for accessing and verifyingthe firmware image, per block 310. If the firmware image is not valid,then the appropriate error handling routine can be initiated. Assuming,however, that the firmware is valid, then the firmware image can beexecuted by the processor, per block 312. The firmware can be configuredto provide functions, such as setting up protected memory locations,memory firewalls, memory access limitations, and the like. In someinstances, these functions can be designed such that they are notmodifiable by subsequently loaded software. It may still be desirable,however, to modify the firmware to allow for changes to these additionalfunctions or for other reasons, such as correcting errors in theinitialization process. As discussed herein, the boot code can includecode for controlling whether the firmware is updated, per block 314. Ifthere is an update to the firmware image, it can be updated byoverwriting the current image with a new image, as shown by block 316.The new image will then be used the next time the processor is booted.

Once the processor has completed updates, if any, to the firmware image,the protection circuit can be enabled by setting the sticky protectionbit, as shown by block 318. Additional software can then be loaded, asindicated by block 320. According to embodiments, the sticky protectionbit is not modifiable by the additional software, and therefore, theprotection circuitry can be configured to remain enabled until thecomputer system is booted another time.

FIG. 4 depicts a flow diagram for a protection circuit, consistent withembodiments of the present disclosure. Consistent with embodimentsdiscussed herein, protection circuitry can provide restrictions onaccess to slave devices that are accessible over a serial interface,such as I2C. For instance, the processor can attempt to access slavedevices by generating requests that are sent to, and received by, an I2Cmaster device and interface, per block 402. These requests can be in theform of writes to configuration registers of the I2C master device. Theprotection circuit can respond to an access request by determiningwhether or not protection is enabled, per block 404. For example, thisdetermination can be made based upon whether or not the sticky bit hasbeen set. If protection is not enabled, the protection circuit can allowthe access request to be sent out on the I2C bus so that the targetslave device can respond to the request, per block 406.

If the protection is enabled, then the protection circuit can beconfigured to determine whether or not the access is a protected accessor an allowed access. As discussed herein, this can included determiningwhether or not the target slave device is protected, per block 408, andwhether or not the type of access is protected. For example, theprotection circuit can compare a target ID/address (which can becontained within the access request) to a list that specifies whichdevices are protected. It is also possible that the protection circuitis configured such that all devices are protected, in which case the useof a list can be avoided altogether. If the target ID is not for aprotected device, then the access request can be sent out on the I2C busso that the target slave device can respond to the request, per block406.

If the protection circuit determines that the target device isprotected, then the protection circuit can be configured to determinewhether or not the particular access is allowed. For example, theprotection circuit can determine whether or not the access is a readaccess, per block 410. If the access is a read access, the protectioncircuit can determine whether or not read protection is enabled, perblock 412. If read protection is not enabled, then the access requestcan be sent out on the I2C bus so that the target slave device canrespond to the request, per block 406. If read protection is enabled,then the request can be denied, per block 416. In some instances, theprotection circuit can be configured to provide an error message to theprocessor.

If the access is not a read, but is instead a write, then the protectioncircuit can be configured to determine whether or not the access requestexceeds a set threshold length, per block 414. This determination can beparticularly useful for protocols, such as I2C, in which a write requestis used to carry out a subsequent read. For instance, I2C slave devicescan be configured to respond to a read request by providing data that isstored in a memory location that is indicated by a local pointerregister. Thus, if the processor seeks to read data from a particularmemory location, it will first attempt to write the particular memorylocation to the local pointer register. Accordingly, if the protectiondevice does not allow any writes, including those to the pointerregister, the read capabilities can be severely degraded and/orunworkable. In particular embodiments, the I2C slave devices can beconfigured to use, for a write request, the first data set of data(e.g., 8 bits) to write to the pointer register. In order to write tomemory within the slave device (as pointed to by the updated pointerregister), additional data is included after the first set of data.Accordingly, if the length of the write request corresponds to athreshold corresponding to a request with only a first set of data, thenthe write request will modify the pointer but not write to thecorresponding memory location. The protection circuit can therefore, beconfigured to allow the pointer register to be updated, so long as readprotection is not enabled, per blocks 412 and 406. If, however, thelength of the write request is over this threshold, then the request canbe denied, per block 416.

The descriptions of the various embodiments of the present disclosurehave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

What is claimed is:
 1. A method of using a protection circuit for usewith a computer system having a master device and at least one slavedevice that are connected by an inter-integrated circuit (I2C) bus, themethod comprising: placing the protection circuit in a permissible mode;receiving a first access request that includes an address thatidentifies a first slave device; communicating, in response to thepermissible mode, the first access request to the first slave deviceusing the I2C bus; setting a sticky protection bit; placing, in responseto the sticky protection bit being set, the protection circuit in aprotected mode; receiving a second access request that includes theaddress that identifies the first slave device; determining that thesecond access request is for a protected access to the first slavedevice; and denying, in response to the determining and the protectedmode, the second access request to the first slave device.
 2. The methodof claim 1, further comprising: setting, in response to a protectionsignal, at least one register bit corresponding to the protected mode;preventing, subsequent to the setting, the sticky protection bit frombeing modified by a write to the register bit; and resetting the atleast one register bit in response to a reboot of the system.
 3. Themethod of claim 1, wherein the determining that the second accessrequest is for the protected access to the first slave device furthercomprises determining that the second access request specifies a sourcedevice address that is in a protection list.
 4. The method of claim 1,wherein the determining that the second access request is for theprotected access to the first slave device comprises: determining thatthe second access request is a read request; and determining that theaddress matches a protected address in a protection list for readrequests.
 5. The method of claim 1, wherein the determining that thesecond access request is for the protected access to the first slavedevice comprises: determining that the second access request is a writerequest; determining that the address matches a protected address in aprotection list; and determining that the second access request exceedsa length that corresponds to writing to a pointer register of the firstslave device.
 6. The method of claim 1, further comprising: receiving athird access request that includes the address that identifies the firstslave device; determining that the third access request is for anallowed access to the first slave device; and communicating, in responseto the determining that the third access request is the allowed accessand the protected mode, the third access request to the first slavedevice using the I2C bus.
 7. The method of claim 6, wherein thedetermining that the third access request is for the allowed access tothe first slave device comprises: determining that the third accessrequest is a write request; determining that the address does not matcha protected address in a protection list for writes.
 8. The method ofclaim 6, wherein the determining that the third access request is forthe allowed access to the first slave device further comprises:determining that the third access request is a read request; anddetermining the address does not match a protected address in aprotection list for reads.
 9. The method of claim 6, wherein thedetermining that the third access request is for the allowed access tothe first slave device further comprises: determining that the thirdaccess request is a write request; determining the address matches aprotected address in a protection list; and determining that the thirdaccess request does not exceed a length that corresponds to writing to apointer register of the first slave device.
 10. The method of claim 1,further comprising: setting a second sticky protection bit; receiving athird access request that includes another address that identifies asecond slave device; determining, based upon a protection listcorresponding to the second sticky protection bit, that the third accessrequest is for a protected access to the second slave device; anddenying the third access request to the second slave device.